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Preface 


This  document  is  one  of  a  new  series  of  publications  of  the  Software  Engineer¬ 
ing  Institute  at  Carnegie  Mellon  University— security  improvement  modules. 
They  are  intended  to  provide  concrete,  practical  guidance  that  will  help  orga¬ 
nizations  improve  the  security  of  their  networked  computer  systems. 

Module  structure 

Each  module  addresses  an  important  but  relatively  narrowly  defined  problem 
in  network  security.  The  first  section  of  the  module  describes  the  problem  and 
outlines  a  set  of  security  improvement  practices  to  help  solve  it.  Each  practice 
is  a  recommended  way  of  performing  common  tasks  related  to  the  secure  oper¬ 
ation  of  networked  computer  systems. 

The  remaining  sections  of  the  module  are  detailed  descriptions  of  the  prac¬ 
tices.  Each  includes  a  rationale  for  the  recommended  actions  and  a  step-by- 
step  description  of  how  to  perform  them. 

Intended  audience 

The  practices  are  written  for  system  and  network  administrators  within  an 
organization.  These  are  the  people  whose  day  to  day  activities  include  instal¬ 
lation,  configuration,  and  maintenance  of  the  computers  and  networks. 

Revised  versions 

Network  technologies  continue  to  evolve  rapidly,  leading  to  both  new  solutions 
and  new  problems  in  security.  We  expect  that  modules  and  practices  will  need 
to  be  revised  from  time  to  time.  To  permit  more  timely  publication  of  the  most 
up-to-date  versions,  the  modules  and  practices  are  also  being  published  on  the 
World  Wide  Web.  At  the  end  of  each  section  of  this  document  is  the  URL  of  its 
Web  version. 

Implementation  details 

How  an  organization  adopts  and  implements  the  practices  often  depends  on 
the  specific  networking  and  computing  technologies  it  uses.  For  some  prac¬ 
tices,  technology-specific  implementation  details  have  been  written  and  are 
being  published  on  the  World  Wide  Web.  The  Web  version  of  each  practice  con¬ 
tains  links  to  the  implementation  details. 
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Who  should  read  these 
practices 


Detecting  Signs  of  Intrusion 


Intruders  are  always  looking  for  new  ways  to  break  into  systems.  They  may 
attempt  to  breach  your  network's  perimeter  defenses  from  remote  locations,  or 
physically  infiltrate  your  organization  to  gain  direct  access  to  its  information 
resources.  Intruders  seek  and  take  advantage  of  newly  discovered  vulnerabili¬ 
ties  in  operating  systems,  network  services  and  protocols.  They  actively 
develop  and  utilize  sophisticated  programs  to  rapidly  penetrate  systems.  As  a 
result,  intrusions,  and  the  damage  they  cause,  are  achieved  in  a  matter  of  sec¬ 
onds. 

This  means  that  even  if  your  organization  has  implemented  comprehensive 
information  security  measures,  it  is  essential  that  your  information  resources, 
and  transactions  involving  them,  be  watched  closely  for  signs  of  intrusion. 
Doing  so  may  be  complicated,  since  intruders  often  cover  their  tracks  by 
changing  the  systems  they  break  into  to  hide  their  activities.  In  other  words, 
an  intrusion  may  have  already  taken  place  but  you  may  not  have  noticed  any¬ 
thing  wrong  because  everything  seems  to  be  operating  normally. 

A  general  security  goal  is  to  prevent  intrusions.  But  because  no  prevention 
measures  are  perfect,  you  also  need  a  strategy  for  handling  intrusions  that 
includes  preparation,  detection,  and  response.  This  module  focuses  on  detec¬ 
tion,  The  practices  recommended  below  are  designed  to  help  you  detect  intru¬ 
sions  by  looking  for  the  “fingerprints”  of  known  intrusion  methods. 


These  practices  are  intended  primarily  for  system  and  network  administra¬ 
tors,  managers  of  information  systems,  and  security  personnel  responsible  for 
networked  information  resources. 

These  practices  are  applicable  to  your  organization  if  your  networked  systems 
infrastructure  includes: 

•  host  systems  providing  services  to  multiple  users  (file  servers,  timesharing 
systems,  database  servers,  Internet  services,  and  so  forth) 

•  internal  local-area  or  wide-area  networks 

•  direct  connections,  gateways,  or  modem  access  to  and  from  external  net¬ 
works,  such  as  the  Internet 


CMU/SEI-SlM-001 


1 


Approach 


The  general  approach  to  detecting  intrusions  is 

1.  Observe  your  systems,  networks,  and  user  activities  for  anything  unusual. 

2.  Investigate  anything  you  find  to  be  unusual. 

3.  If  your  investigation  finds  something  that  isn’t  explained  by  authorized 
activity,  immediately  initiate  your  intrusion  response  procedures. 

While  this  process  soimds  simple  enough,  implementing  it  is  a  resource-inten¬ 
sive  activity  that  requires  continuous,  automated  support  and  daily  adminis¬ 
trative  effort.  Furthermore,  the  scale  of  intrusion-detection  practices  may 
need  to  change  as  threats,  system  configurations,  or  security  requirements 
change.  In  all  cases,  however,  there  are  five  areas  that  must  be  addressed: 

•  Integrity  of  the  software  you  use  to  detect  intrusions 

•  Integrity  of  your  file  systems  and  the  program  and  data  files  they  contain 

•  Operations  of  your  systems  and  the  traffic  on  your  networks 

•  Physical  forms  of  intrusion  to  your  computer  systems,  offline  data  storage 
media,  and  output  devices 

•  Investigation  of  reports  by  users  and  other  reliable  sources  (such  as  inci¬ 
dent  response  teams)  of  unusual  activities  associated  with  your  networked 
information  resources 

As  you  look  for  signs  of  intrusion,  keep  in  mind  that  information  from  one 
source  may  not  appear  suspicious  by  itself.  Inconsistencies  among  several 
sources  can  sometimes  be  the  best  indication  of  suspicious  activities  or  intru- 
sions. 


Summary  of 
recommended  practices 


Area 

Recommended  Practices 

Integrity  of 

intrusion-detection 

software 

1.  Ensure  that  the  software  used  to  examine 
systems  has  not  been  compromised. 

Integrity  of  file 
systems  and 
sensitive  data 

2.  Look  for  unexpected  changes  to  directories  and 
files. 

System  and  network 
activities 

3.  Inspect  your  system  and  network  logs. 

4.  Review  notifications  from  system  and  network 
monitoring  mechanisms. 

5.  Inspect  processes  for  unexpected  behavior. 

Physical  forms  of 
intrusion 

6.  Investigate  unauthorized  hardware  attached  to 
your  organization’s  network. 

7.  Look  for  signs  of  unauthorized  access  to  physical 
resources. 

Other  sources  of 
information 

8.  Review  reports  by  users  and  external  contacts 
about  suspicious  system  and  network  events  and 
behavior. 
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Where  to  find  updates 


The  latest  version  of  this  module  is  available  on  the  Web  at  URL 

http; //WWW. cert. org/security-improvement/modules/mOl .html 
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Ensure  that  the  software  used  to  examine  systems 
has  not  been  compromised. 


Why  this  is  important 


When  looking  for  signs  of  intrusions  on  your  systems,  and  when  examining 
your  systems  in  general,  you  should  use  a  verified,  reference  set  of  software— 
one  that  contains  only  genuine  copies  of  software  that  have  not  been  modified. 
In  addition  to  executable  programs,  the  verified  set  of  software  must  include 
all  the  system  libraries,  configuration  and  data  files,  and  system  utilities  on 
which  the  programs  depend.  You  should  avoid  rel5dng  on  software  that  resides 
on  systems  being  inspected  (unless  you  can  verify  that  the  software  and  its 
supporting  libraries,  configuration  files,  and  data  files  have  not  been  modi¬ 
fied). 


Intrusion  detection  depends  heavily  on  the  reliability  of  the  information  you 
gather  about  the  state  and  behavior  of  your  systems,  networks,  data,  and  user 
activities.  Therefore,  it  is  essential  that  you  use  only  software  that  you  know 
to  be  genuine  and  accurate  in  its  reporting  of  such  information. 

Intruders  often  replace  software  that  would  reveal  their  presence  with  substi¬ 
tutes  that  obscure  or  remove  such  information.  Intruders  are  known  to  have 
replaced  programs,  Ubraries,  and  other  utilities  called  by  the  programs.  If  a 
program  used  in  detecting  intrusions  has  been  tampered  with  or  substituted, 
you  cannot  rely  on  its  output. 

Ensuring  that  you  are  using  only  verified  software  may  be  very  difficult.  Mod¬ 
ifications  that  intruders  make  to  systems  can  be  extremelj'  devious  and  make 
things  appear  to  be  normal  when  in  fact  they  are  not.  For  example,  the  ps 
command  on  a  UNIX  system  may  be  replaced  with  one  that  does  not  display 
the  intruder’s  process,  or  an  editor  can  be  replaced  with  one  that  will  read  a 
file  different  from  the  one  specified  (the  intruder  may  have  hidden  the  original 
file  and  replaced  it  with  another  version).  Intruders  also  have  been  known  to 
modify  software  that  is  executed  at  system  boot  and  shutdown,  complicating 
your  ability  to  safely  take  a  system  down  for  more  detailed  analysis. 
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The  guiding  principle  for  this  practice  is  that  you  maintain  a  certain  amount 
of  suspicion.  Question  everything  you  see,  and  try  to  ans'wer  the  question, 
“What  software  is  producing  this  output?” 

There  are  five  general  ways  to  achieve  the  goal  of  using  a  verified  set  of  soft¬ 
ware,  and  each  way  has  advantages  and  disadvantages.  You  should  choose  a 
method  appropriate  to  your  current  circumstances. 

In  all  cases,  the  verified  software  should  be  located  on  physically  write-pro¬ 
tected  media  (e.g.,  CD-ROM  or  write-protected  disk),  so  that  it  cannot  be  mod¬ 
ified  by  a  user  or  software  running  on  the  system  being  examined. 

>-  Move  the  disk  from  the  suspect  system  to  a  write-protected,  verified  system  and 
examine  the  disk’s  contents  using  the  software  of  the  protected  system. 

This  method  has  the  advantage  that  you  need  not  rely  on  the  validity  of  any 
part  of  the  operating  system  or  the  hardware  on  the  suspect  system. 

The  method  is  effective  and  reasonable  when  you  suspect  that  a  particular 
system  has  been  compromised  and  want  to  analyze  it.  However,  it  may  not  be 
practical  for  automated  procedures  or  for  checking  a  large  number  of  systems. 

Be  careful  when  shutting  down  the  suspect  system  since  the  mere  act  of  doing 
so  may  result  in  hiding  the  evidence  you  are  seeking.  Before  shutting  down 
the  suspect  system,  look  at  any  programs  that  will  rvm  at  shutdown  for  signs 
that  they^ve  been  modified  (for  example  in  some  UNIX  operating  systems,  the 
/eto/shutdown  program  should  be  examined).  But  be  aware  that  just  look¬ 
ing  at  the  file  may  be  misleading  since  you  are  relying  on  the  software  on  the 
suspect  system.  So,  to  be  completely  safe,  you  may  want  to  execute  verified 
copies  of  shutdown  programs  emd  their  data  files  (taking  care  to  save  the  orig¬ 
inal  files  for  later  analysis).  Other  alternatives  are  to  execute  the  shutdown 
from  external  media,  force  the  system  to  halt  immediately  (e.g.,  LI ,  A  on  a 
UNIX  system),  or  just  pull  the  plug. 

>-  Attach  to  the  suspect  system  a  write-protected,  verified  system  disk  that  con¬ 
tains  the  operating  system  and  all  needed  software,  and  then  reboot  the  system 
using  the  verified  operating  system. 

This  method  has  similar  advantages  and  disadvantages  to  those  of  the  method 
above,  but  relies  on  the  trustworthiness  of  the  hardware  of  the  suspect  sys¬ 
tem. 

>■  Generate  an  image  of  the  suspect  system  disk,  mount  it  on  a  verified  system, 
and  examine  it  there. 

This  method  is  acceptable  if  you  have  a  verified  system  that  you  can  use  for 
this  purpose.  An  advantage  of  this  approach  is  that  you  won’t  affect  the  oper¬ 
ational  environment  of  the  suspect  system  because  you’re  looking  at  an  image 
of  it  on  another  system. 

>■  Use  external  media  containing  a  verified  set  of  software  to  examine  the  suspect 
system. 

To  use  this  method,  you  need  a  CD-ROM  or  write-protected  diskette  contain- 


How  to  do  it 
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ing  verified  software  to  be  used  when  checking  the  suspect  system. 

A  significant  concern  with  this  approach  is  that  you  will  still  be  using  the 
operating  system  of  the  suspect  system  (e.g.,  the  UNIX  kernel),  and  it  may  be 
difficult,  if  not  impossible,  to  ensure  that  you  have  provided  every  needed  pro¬ 
gram,  utility,  and  library. 

>  Verify  the  software  on  the  suspect  system  first,  then  use  it  to  examine  the  sys¬ 
tem. 

This  method  will  require  that  you  compare  the  software  on  the  suspect  system 
with  a  reference  copy  (either  complete  files  or  cryptographic  checksums).  How¬ 
ever,  care  must  be  taken  to  use  a  verified  comparison  program  or  crypto¬ 
graphic  checksumming  program.  The  program  used  to  verify  the  software 
should  be  located  on  a  hardware  write-protected  medium. 


Policy  considerations  Your  organization’s  networked  systems  security  policy  should. 

•  Specify  the  level  of  verification  that  is  required  when  examining  each  class 
of  data  and  service  provided  by  the  organization. 


Other  information  Some  operating  systems  provide  the  capability  to  make  files  immutable, 

meaning  unchangeable  by  any  process  on  the  system,  including  system  and 
administrative  processes.  All  operating  system  files  that  don’t  need  to  be  mod¬ 
ified  when  a  system  is  running  can  be  made  immutable. 

When  you  are  examining  your  system  through  a  remote  access  cormection, 
you  need  to  be  sure  that  you  have  established  a  secure  channel  to  the  system 
so  that  only  authorized  personnel  use  the  channel  and  nothing  is  changed  in 
transit. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected 

technologies,  is  available  on  the  Web  at  URL: 

http : / /www . cert . org/security-in^rovement/practices/pOOl . html 
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Look  for  unexpected  changes  to  directories  and  files. 


Why  this  is  important 


How  to  do  it 


The  file  systems  in  your  network  environment  contain  a  variety  of  software 
and  data  files.  Unexpected  changes  in  directories  and  files,  especially  those  to 
which  access  is  normally  restricted,  may  be  an  indication  that  an  int^sion 
has  occurred.  Changes  may  include  modifying,  creating,  or  deleting  directories 
and  files.  What  makes  such  changes  unexpected  may  depend  on  who  changed 
them  and  where,  when,  and  how  the  changes  were  made. 


Intruders  often  substitute,  modify,  and  damage  files  on  systems  to  which  they 
have  gained  access.  To  hide  their  presence  on  your  systems,  it  is  common  for 
intruders  to  replace  system  programs  with  substitutes  that  perform  the  same 
functions  but  exclude  information  that  could  reveal  their  illicit  activities.  They 
also  often  modify  system  log  files  to  remove  traces  of  their  activities.  By  mask¬ 
ing  their  presence  on  a  compromised  system,  intruders  prolong  the  time  they 
have  to  use  that  system  for  their  purposes.  In  several  notable  cases,  the  pres¬ 
ence  of  intruders  on  compromised  systems  was  not  discovered  until  many 
months  after  the  initial  intrusion  occurred. 

Intruders  may  also  create  new  files  on  your  systems.  For  example,  they  may 
install  backdoor  programs  or  tools  used  to  gain  privileged  access  on  the  sys¬ 
tem.  Intruders  also  make  use  of  the  disk  space  on  compromised  systems  to 
store  their  tools  and  contraband. 

Private  data  files  and  files  containing  mission-critical  information  are  com¬ 
mon  targets  of  modification  or  corruption  by  intruders.  Information  about 
your  organization  that  is  accessible  to  the  public  or  to  subscribers  via  public 
networks  and  the  Internet  is  also  a  common  target.  Several  documented  cases 
exist  of  prominent  organizations  that  have  had  their  Web  sites  modified  to 
include  offensive  content  and  other  erroneous  information. 


>•  Establish  priorities  and  schedules. 

Examine  the  files  on  your  system  and  prioritize  the  frequency  with  which  they 
should  be  checked.  The  more  mission-  or  security-critical  the  file,  the  more  fre¬ 
quent  the  checking  should  be. 

>•  Maintain  authoritative  reference  data  for  critical  files  and  directories. 

For  each  file  and  directory,  the  authoritative  reference  data  you  maintain 
should  provide  enough  information  for  you  to  be  able  to  identify  changes  to 


Policy  considerations 


•  location  in  the  file  system 

•  alternate  paths  to  it,  via  links,  aliases,  or  shortcuts 

•  contents  of  files,  entries  in  directories 

•  exact  size,  and  if  possible,  file  system  units  allocated 

•  time  and  date  indicating  when  the  file  or  directory  was  created  and  last 
modified 

•  ownership  and  access  permission  settings,  including  execution  privilege 
settings  for  software 

Use  robust  ciyptographic  checksum  technologies  to  generate  a  checksum  for 
each  file.  Keep  authoritative  copies  of  files  and  checksums  on  write-protected 
or  read-only  media  stored  in  a  physically  secure  location. 

>■  Verify  the  integrity  of  directories  and  files  according  to  your  established  sched¬ 
ule. 

Compare  the  attributes  and  contents  of  files  and  directories  to  the  authorita¬ 
tive  reference  (either  complete  copies  or  cryptographic  checksums).  Identify 
any  files  and  directories  whose  contents  or  other  attributes  have  changed. 

Always  access  authoritative  reference  information  directly  fi'om  its  secured, 
read-only  media.  Never  transmit  authoritative  reference  information  over 
unsecured  network  connections. 

>  Identify  any  missing  files  or  directories. 

>■  Identify  any  new  files  and  directories. 

Pay  special  attention  to  any  new  program  files  and  their  associated  execution 
privilege  settings. 

>•  Investigate  any  unexpected  changes  among  those  you  have  identified. 

If  any  changes  cannot  be  attributed  to  authorized  activity,  initiate  your  intru¬ 
sion-response  procedures  immediately. 

Report  the  incident  to  your  organization’s  designated  security  point  of  contact. 


Your  organization’s  networked  systems  security  policy  should 

•  Define  the  responsibilities  and  authority  of  systems  administrators  and 
security  personnel  to  examine  file  systems  on  a  regular  basis  for  unex¬ 
pected  changes.  Users  should  be  told  about  such  authority  and  examina¬ 
tion. 

•  Require  users  to  report  any  unexpected  changes  to  their  software  and  data 
files  to  system  administrators  or  your  organization’s  designated  security 
point  of  contact. 
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other  information 


Where  to  find  updates 


As  authorized  and  expected  changes  are  made  to  files  and  directories,  you  will 
need  to  perform  your  organization’s  procedures  for  securely  updating  your 
authoritative  reference  data. 

Some  kinds  of  important  files  are  expected  to  change  frequently  (perhaps  sev¬ 
eral  times  per  second);  these  include  system  log  files,  transaction  log  files,  and 
database  tables.  In  general,  the  techniques  described  above  will  not  be  partic¬ 
ularly  useful  in  distinguishing  normal  changes  to  such  files  from  those  that 
might  have  been  caused  by  intruders.  Techniques  based  on  transaction  audit- 
ing  are  more  useful  in  these  cases. 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected 
technologies,  is  available  on  the  Web  at  URL 

http : //WWW . cert . org/ security- improvement/practices/pO 02 . html 
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Inspect  your  system  and  network  logs. 


Frequently,  intruders  leave  traces  of  their  actions  in  system  log  files.  Hence, 
checking  system  and  network  log  files  periodically  is  one  way  to  detect  intru- 
sions. 


Why  this  is  important  Logs  may  contain  evidence  of  unusual  and  imexpected  activities  that  have 

occurred  on  the  system  or  network.  Such  log  entries  may  indicate  that  some¬ 
one  has  compromised  or  tried  to  compromise  the  system.  By  looking  at  log  files 
on  a  regular  basis,  you  may  be  able  to  identify  attempted  or  successful  intru¬ 
sions  soon  after  they  occur  and  initiate  the  proper  damage-prevention  or  con¬ 
tainment  procedures. 


Background  Information  Log  files  vary  depending  on  the  operating  system,  application  software  run¬ 
ning  on  the  system,  and  logging  configuration  you  have  chosen.  Multiuser 
operating  systems  often  provide  more  extensive  logging  capabilities  than  do 
single-user  operating  systems.  Table  1  describes  information  typically  con¬ 
tained  in  logs. 


Type  of  Log 

Information  Contained  in  the  Log 

user  activity 

•  login  activity 

•  changes  in  user  identity 

•  file  accesses  by  the  user 

•  authorization  information 

•  authentication  information 

process  activity 

•  commands  run  by  users 

•  running-process  information  including  program  name, 
user,  start  and  stop  times,  and  execution  parameters 

system  activity 

•  restarts  and  shutdowns  of  the  system 

•  administrative  logins 

network 

connections 

•  details  (when,  where,  what  kind)  of  connections 
attempted  or  established  with  the  system 

•  details  of  connections  established  from  the  system 

network  traffic 
monitoring 

•  records  of  all  network  traffic  transactions 

program-specific 
log  files 

•  details  of  the  specific  program’s  behavior 
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How  to  do  it 


>•  Periodically  inspect  each  type  of  log  file. 

We  recommend  that  each  log  file  be  inspected  at  least  daily. 

Look  for  evidence  of  unusual  or  unexpected  activity.  One  benefit  of  periodic 
inspections  is  that,  over  time,  you  will  become  increasingly  familiar  with  the 
signs  of  usuoZ  and  expected  activity  This  will  make  it  easier  to  recognize  the 
unusual  and  unexpected. 

The  table  below  summarizes  unusual  or  unexpected  activities  that  may  be 
reported  in  each  log  type.  For  operating  systems  that  support  different  levels 
of  user  privilege,  be  sure  to  look  for  unusual  activity  by  users  at  all  levels. 


Type  of  Log 

Unusual  or  Unexpected  Activities 

user  activity 

•  repeated  failed  login  attempts 

•  logins  from  unexpected  locations 

•  logins  at  imusual  times  of  day 

•  unusual  attempts  to  change  user  identity 

•  unusual  processes  run  by  users 

•  unauthorized  attempts  to  access  restricted  files 

process  activity 

•  processes  that  are  run  at  unexpected  times 

•  processes  that  have  terminated  prematurely 

•  unusual  processes  (i.e.,  those  not  due  to  normal,  autho¬ 
rized  activities) 

system  activity 

•  unexpected  shutdowns 

•  unexpected  reboots 

network 

connections 

•  connections  to  or  from  unusual  locations 

•  repeated  failed  connection  attempts  and  their  origina¬ 
tion  and  destination  addresses  and  ports 

•  connections  made  at  unusual  times 

•  unexpected  network  traffic  (i.e.,  contrary  to  your  fire¬ 
wall  configuration  or  unexpected  traffic  volume) 

network  traffic 
monitoring 

•  sweeps  of  your  network  address  space  for  various  ser¬ 
vices,  indicating  attempts  to  identify  hosts  on  your  net¬ 
work  and  the  services  they  run 

•  repeated  half-open  connections  (may  signify  IP  spoof¬ 
ing  attempts,  or  denial  of  service  activity) 

•  successive  attempts  to  connect  to  unusual  services  on 
your  network’s  hosts 

•  transactions  originating  outside  your  network  with 
destinations  also  outside  your  network  (signifying  traf¬ 
fic  that  should  not  be  traversing  your  network) 

•  sequential  (attempted)  connections  to  specific  services 
signifying  someone  trying  to  run  network-probing  tools 
against  your  networked  systems 
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Type  of  Log 

Unusual  or  Unexpected  Activities 

program-specific 
log  files 

The  presence  and  content  of  program-specific  logs 
depend  entirely  on  the  program.  The  following  are  only 
examples  of  the  kinds  of  logging  that  may  occur: 

•  unusual  uses  of  outgoing  modems 

•  excessive  or  unusual  file  transfers 

•  unusual  entries  from  mail  utilities 

•  excessive  mailings 

•  unusual  database  transactions 

►  Document  uny  unusual  entries  that  you  discover. 

Over  time,  you  may  see  recurring  kinds  of  unusual  log  file  entries.  Maintain¬ 
ing  records  of  such  entries  and  what  you  determined  to  be  their  causes  will 
help  you  and  others  to  understand  new  occurrences  more  quickly  and  accu¬ 
rately. 

>■  Investigate  each  documented  abnormality. 

Ask  yourself  questions  such  as 

•  Can  it  be  explained  by  the  activities  of  an  authorized  user?  (e.g.,  the  user 
really  was  in  Cairo  last  week  and  coimected  to  the  network) 

•  Can  it  be  explained  by  known  system  activity?  (e.g.,  there  was  a  power  out¬ 
age  that  caused  the  system  to  reboot) 

•  Can  it  be  explained  by  authorized  changes  to  programs?  (e.g.,  the  mail  log 
showed  abnormal  behavior  because  the  system  programmer  made  a  mis¬ 
take  when  the  software  was  modified) 

>•  Report  all  confirmed  evidences  of  intrusion  (or  attempted  intrusion)  to  your 
organization’s  internal  security  point  of  contact. 

>  Read  security  bulletins  from  trustworthy  sources  (e.g.,  CERT®^  advisories  and 
summarie^)  and  other  security  publications  regularly. 

This  can  increase  your  understanding  of  current  intruder  activities  and  meth¬ 
ods,  and  you  can  use  this  information  to  improve  what  you  look  for  in  log  files. 


Policy  considerations 

Your  organization’s  networked  systems  security  policy  should: 

•  Specify  that  log  files  be  inspected  on  a  regular  basis  by  authorized  person¬ 
nel,  and  that  anomalies  be  recorded  and  reported  to  your  organization  s 
designated  security  point  of  contact. 

Other  information 

If  your  site  has  large  networks  of  systems  with  many  log  files  to  inspect,  con¬ 
sider  using  tools  that  collect  and  consolidate  log  file  information.  Over  time, 
you  will  learn  what  is  normal  for  your  environment.  You  should  integrate  this 

1.  Registered  in  the  U.S.  Patent  and  Trademark  Office. 

2.  See  http://www.cert.org  and  ftp://info.cert.org/pub/cert_advisories/  . 
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Where  to  find  updates 


knowledge  into  your  site’s  specific  procedures  for  inspecting  log  files. 

Also,  as  you  acquire,  modify,  or  retire  systems,  your  log  review  procedures  may 
need  to  change.  Make  sure  that  your  site’s  procedures  are  appropriate  for  your 
current  technology. 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected 
technologies,  is  available  on  the  Web  at  URL 

http: / / WWW. cer t . org/ security- improvement /practices /pO 03 .html 
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Review  notifications  from  system  and  network 
monitoring  mechanisms. 


If  you  have  intrusion  detection  mechanisms  monitoring  your  systems,  you 
should  investigate  any  warnings  they  soxmd.  Although  monitors  are  not  fool 
proof,  they  can  be  part  of  an  effective  early  warning  system  against  certain 
types  of  attacks. 


Why  this  is  important 


The  monitoring  of  processes  provides  the  capability  to  identify  intrusive  activ¬ 
ity  at  the  time  it  is  occurring  or  soon  after.  By  catching  suspect  activity  as 
early  as  possible,  you  can  immediately  begin  to  investigate  the  activity  an 
minimize  the  damage. 


How  to  do  It  >■  Notify  users  that  process  monitoring  is  being  done. 

In  most  cultures  today,  monitoring  users’  activities  may  be  considered  ^ 
unwarranted  invasion  of  privacy.  Be  sure  to  inform  authorized  users  of  your 
networked  systems  about  the  scope  and  kind  of  monitoring  you  will  be  domg. 

>■  When  a  notification  is  generated,  examine  it  to  see  if  it  is  caused  by  authorized 
activity. 

If  it  is  not,  notify  your  organization’s  designated  security  point  of  contact. 

>■  Update  monitoring  configurations  when  information  on  new  attack  methods  is 
published. 


Policy  considerations  Your  organization’s  networked  systems  security  policy  should 

•  Require  the  notification  of  users  regarding  the  monitoring  that  will  be 
done. 

•  Specify  which  data  streams  will  be  monitored  and  for  what  purposes. 

•  Define  the  responsibilities  of  system  administrators  for  handling  notifica¬ 
tions  generated  by  monitoring  software. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected 

technologies,  is  available  on  the  Web  at  URL: 

http://www.cert.org/securitY-improveinent/practices/p004 .html 
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Inspect  processes  for  unexpected  behavior. 


Why  this  is  important 


How  to  do  it 


Programs  executing  on  your  networked  systems  typically  include  a  variety  of 
operating  system  and  network  services,  user-initiated  programs,  and  special- 
purpose  applications  such  as  database  servers.  Every  program  executing  on  a 
system  is  represented  by  one  or  more  processes.  Each  process  executes  in  an 
environment  with  specific  privileges  that  govern  what  system  resources  pro¬ 
grams,  and  data  files  it  can  access,  and  what  it  is  permitted  to  do  with  them. 


The  execution  behavior  of  a  process  is  represented  by  the  operations  it  per¬ 
forms  while  running,  the  manner  in  which  those  operations  execute  ^d  the 
system  resources  it  uses  while  executing.  Operations  include  computations 
transactions  with  files,  devices,  and  other  processes,  and  communications  with 
processes  on  other  systems  via  your  network. 


The  goal  is  to  verify  that  the  processes  executing  on  your  systems  are  ^tnb- 
uted  only  to  authorized  activities  of  users,  administrators,  and  system  func¬ 
tions,  and  are  operating  only  as  would  be  expected. 

A  process  that  exhibits  unexpected  behavior  may  indicate  that  an  intmsion 
into  a  system  has  occurred.  Intruders  may  have  disrupted  the  execution  of  a 
program  or  service,  causing  it  to  fail,  or  to  operate  in  a  way  other  than  the 
user  or  administrator  intended.  For  example,  if  intruders  were  to  successfolly 
disrupt  the  execution  of  access-control  processes  runnmg  on  a  firewall  system, 
they  may  be  able  to  gain  access  to  your  organization’s  internal  network  m 
ways  that  would  normally  be  blocked  by  the  firewall.  Unexpected  processes 
may  also  indicate  that  an  intruder  is  using  the  system  covertly  for  unautho¬ 
rized  purposes,  including  attempts  to  attack  other  systems  within  and  exter¬ 
nal  to  your  network,  or  running  network  sniffer  programs. 


>-  Notify  users  that  process  inspection  is  being  done. 

In  most  cultures  today,  monitoring  users’  activities  may  be  considered  an 
unwarranted  invasion  of  privacy.  Be  sure  to  inform  authorized  users  of  your 
networked  systems  about  the  scope  and  kind  of  process  inspections  you  will  be 
doing. 


►  To  the  extent  that  you  are  able,  continuously  monitor  processes,  network  socket 
status,  open  files,  and  device  activity  on  your  networked  systems. 

The  examination  of  processes  is  complex,  time  consuming,  ^d  resource  inten¬ 
sive.  The  degree  to  which  you  will  be  able  to  identify  suspicious  processes  will 


depend  on  your  knowledge  of  what  processes  you  would  normally  expect  to  be 
executing  on  a  given  system  and  how  they  should  behave. 

As  a  general  guideline,  you  should  look  for 

•  missing  processes 

•  extra  processes 

•  unusual  process  behavior  or  resource  utilization 

•  processes  that  have  unusual  user  identification  associated  with  them 

Due  to  the  large  number  of  processes  and  their  rapidly  changing  natures,  it  is 
impractical  for  you  to  monitor  them  continually  yourself.  In  addition,  the 
amount  and  value  of  information  that  you  can  gather  from  a  snapshot  of  cur¬ 
rently  executing  processes  may  be  very  limited.  This  means  that  you  must 
employ  a  variety  of  information-gathering  and  monitoring  mechanisms  to  help 
you  collect  and  analyze  data  associated  with  processes,  and  to  alert  you  to  sus¬ 
picious  activity. 

One  common  approach  with  multiuser  systems  is  to  set  up  consoles  (or  termi- 
nal  windows  on  graphical  workstations)  that  display  the  current  status  of  pro¬ 
cesses  and  are  updated  at  short  intervals.  IdeaUy,  these  consoles  should  be 
hard-wired  to  the  systems  for  which  they  are  displaying  information.  With 
strategic  placement  of  these  displays,  you  can  take  advantage  of  the  experi¬ 
ence  of  system  administrators  and  operators  to  notice  unexpected  activity  that 
may  not  be  picked  up  by  your  automated  system  and  network  monitoring 
mechanisms. 

More  generally,  there  are  several  sources  of  information  that  will  help  you  to 
analyze  the  behavior  of  processes; 

•  logs  from  programs  that  collect  and  record  information  about 

-  process  accounting  (i.e.  who  executed  what  programs  when,  where,  how 
long  the  processes  took,  and  what  resources  they  accessed) 

-  login  and  network  connection  attempts 

-  attempts  to  access  restricted  resources  and  data 

-  transactions  with  specific  network  services  (e.g.,  Web  servers) 

•  output  from  programs  that  tell  you  about 

-  the  state  of  current  processes  on  your  systems 

-  the  configuration  of  resources  and  devices  on  your  systems 

-  which  resources  and  devices  are  currently  being  used  by  processes  and 
how 

-  files  currently  open  by  processes  on  your  system 

-  the  states  and  activities  associated  with  network  sockets  currently  open 
on  your  system 

•  system-  and  network-monitoring  programs  that  alert  you  when  they  find 

-  unexpected  volume  or  types  of  resource  usage  on  a  system 

-  attempts  to  log  into  systems  with  privileged  (e.g.,  administrator)  access 

-  attempts  to  access  sensitive  system  data  files  or  restricted  resources 

-  unexpected  volume  and  types  of  network  traffic 

-  network  interfaces  operating  in  promiscuous  mode 

-  other  unexpected  changes  to  hardware  configuration  settings 
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>  As  events  give  you  reason  to  believe  that  intrusive  activity  may  be  taking  place, 
examine  any  suspect  processes. 

There  are  typically  several  questions  that  you  may  need  to  answer  when  ^a- 
lyzing  processes  to  determine  if  they  are  authorized  and  behaving  normally. 
We  recommend  that  you  adopt  or  develop  a  checklist  of  such  questions  to 
enable  a  structured  and  repeatable  analysis  procedure. 

When  examining  suspect  processes,  bear  in  mind  the  recommendations  in  the 
practice  “Ensure  that  the  software  used  to  examine  systems  has  not  been  com¬ 
promised.". 

>►  If  you  notice  unusual  activity  associated  with  particular  users,  initiate  supple¬ 
mental  logging  and  monitoring  mechanisms  to  gather  detailed  information 
about  those  users’  activities  on  your  systems  and  networks. 

Many  multiuser  systems  provide  facilities  to  audit  all  processes  associated 
with  a  particular  user.  Since  process  accounting  logs  tend  to  generate  a  great 
deal  of  information  rapidly,  you  will  need  to  dedicate  sufficient  resources  to 
store  the  data  collected.  Similarly,  detailed  network  logging  of  all  activity 
associated  with  all  the  systems  accessed  by  a  specific  user  can  be  voluminous, 
and  you  will  need  to  allocate  resources  accordingly.  Review  the  newly  collected 
data  often  (at  least  daily)  to  minimize  the  amount  of  information  that  you 
have  to  analyze  at  any  given  time. 


Policy  considerations 

Your  organization’s  networked  systems  security  policy  should 

•  Require  notification  of  users  regarding  the  process  inspections  that  will  be 
done. 

•  Specify  the  responsibilities  and  authority  of  designated  systems  admmis- 
trators  and  security  personnel  to  examine  processes  for  unexpected  behav- 

ior. 

•  Specify  what  forms  of  unexpected  behavior  users  should  watch  for.  Require 
users  to  report  any  such  behavior  to  their  designated  security  officials  and 
system  administrators. 

•  Specify  what  software  and  data  users  and  administrators  are  permitted  to 
install,  collect,  and  use,  with  explicit  procedures  and  conditions  for  doing 

SO. 

•  Specify  what  programs  users  and  administrators  are  permitted  to  execute 
and  under  which  conditions. 

other  information 

One  common  activity  of  intruders  is  to  gather  information  from  the  traffic  on 
your  networks  to  find  user  account  names,  passwords,  and  other  information 
that  may  facilitate  their  ability  to  gain  access  to  your  systems.  They  do  this  by 
breaking  into  one  system  on  your  network  and  executing  on  it  &  packet  sniffer 
program.  This  program  collects  information  about  connections  established 
between  systems  from  network  data  packets  as  they  arrive  at  or  pass  by  the 
compromised  system.  To  hide  this  illicit  activity  on  compromised  systems, 
intruders  typically  modify  log  files  and  replace  programs  that  would  reveal 
the  presence  of  the  sniffer  program  with  “Trojan  horse”  versions.  The  substi¬ 
tute  programs  appear  to  perform  the  same  functions  but  exclude  information 
associated  with  the  intruders  and  their  activities.  In  many  documented  cases 

- - — - - -  —  ^ 
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Where  to  find  updates 


of  this  type  of  intrusion,  the  intruders’  activities  went  unnoticed  for  a  consid¬ 
erable  amount  of  time,  during  which  they  collected  enough  information  to  gain 
privileged  access  to  several  other  systems. 

This  underscores  the  importance  of  using  verified  software  to  examine  your 
systems  and  the  need  to  verify  the  integrity  of  your  files,  as  described  in  other 
practices.  Unfortunately,  there  are  several  sophisticated  collections  of  pro¬ 
grams  that  intruders  can  use  to  rapidly  gain  access  to  systems  and  “set  up 
shop”  to  install  and  execute  a  packet  sniffer.  This  means  that  the  only  means 
you  may  have  to  catch  such  activity  is  to  use  verified  software  to  examine  pro¬ 
cesses  on  your  systems  for  unexpected  behavior.  Processes  associated  with  a 
packet  sniffer  will  typically  have  transactions  with  a  network  interface  that 
has  been  placed  in  promiscuous  mode^,  as  well  as  a  file  or  network  connection 
to  which  the  information  gathered  from  network  packets  is  being  sent. 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected 
technologies,  is  available  on  the  Web  at  URL: 

http : / /www . cert . org/security-improv®nent/practices/p005 . html 


1.  Network  interfaces  on  most  systems  normally  operate  in  non-promiscuous  mode, 
which  me^ms  that  they  ignore  network  packets  not  explicitly  addressed  to  them.  In 
promiscuous  mode,  no  packets  are  ignored,  that  is,  all  packets  that  traverse  the 
network  segment  to  which  the  system  is  attached  are  read  by  its  network  interface 
and  are  accessible  to  processes  executing  on  that  system. 
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Investigate  unauthorized  hardware  attached  to  your 
organization’s  network. 


UnauthorizBci  hardware  may  include  computers  connected  to  network  seg¬ 
ments  or  hubs,  and  peripheral  communication  or  input/output  equipment 
such  as  modems,  terminals,  printers,  and  disk  or  tape  drives. 


Why  this  is  important  Intruders  actively  attempt  to  circumvent  network  perimeter  defenses.  If  they 

can  gain  physical  access  to  your  organization’s  internal  network,  they  can 
install  their  own  equipment  and  software.  Alternatively,  intruders  may  learn 
of  insecure  (unauthorized)  equipment  added  by  users  that  they  can  use  to  gain 
access  to  the  organization’s  network.  For  example,  users  might  install  modems 
for  the  purpose  of  remote  access  to  their  office  computers  from  home.  Intrud¬ 
ers  often  use  automated  tools  to  identify  such  modems  attached  to  public  tele¬ 
phone  lines.  If  the  configuration  of  the  dial-up  access,  and  the  traffic  through 
it,  is  not  secured,  intruders  may  use  such  back  doors  to  gain  access  to  the 
internal  network,  b3q)assing  preventative  measures  that  may  have  been  put  in 
place  to  restrict  external  connections  to  the  organization’s  network.  They  may 
then  capture  network  traffic,  infiltrate  other  systems,  disrupt  operations,  and 
steal  sensitive,  private  information. 

Access  to  other  peripheral  equipment  may  also  facilitate  intrusions.  Unse¬ 
cured  output  and  removable  media  devices,  such  as  printers  and  diskette 
drives,  may  give  intruders  the  opportunity  to  generate  copies  of  sensitive 
information  that  can  be  physically  removed  from  your  organization  s  pre¬ 
mises. 


How  to  do  it  ^  Perform  a  monthly  ‘^walkabout”  audit  of  all  systems  and  peripherals  attached 

to  the  network  infrastructure. 

Visits  to  physically  examine  equipment  attached  to  the  network  should  not  be 
annoimced,  so  that  unauthorized  equipment  cannot  be  hidden  before  the  audi¬ 
tors  arrive. 

Using  your  documented  hardware  inventory,  identify  any  missing  hardware, 
hardware  that  is  not  in  its  expected  location,  and  any  unexpected,  extra  hard¬ 
ware. 

On  a  daily  basis,  probe  for  unauthorized  modems  attached  to  your  organiza¬ 
tion's  telephone  lines. 

You  can  do  this  using  “demon  dialer”  tools.  Because  this  process  will  cause  all 
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Policy  considerations 


telephones  in  your  organization  to  ring,  we  recommend  that  it  be  done  during 
nonworking  hours. 


>  On  a  daily  basis,  probe  all  internal  network  segments  to  identify  devices 

attached  to  them.  You  can  do  this  using  a  variety  of  commercial  network  man¬ 
agement  software  packages. 

Identity  any  missing  hardware,  hardware  that  is  not  in  its  expected  location, 
and  any  unexpected,  extra  hardware. 


> 


On  a  daily  basis,  look  for  unexpected  routes  between  the  organization’s  network 
and  external  networks. 


Examine-the  network  traffic  logs  for  connections  that  originate  outside  your 
network  and  are  destined  for  addresses  outside  your  network.  Such  transit 
traffic  may  indicate  that  an  unauthorized  computer  is  connecting  to  one  of 
your  hosts.  Although  in  this  case,  the  extra  hardware  will  probably  not  be  ^ 
located  at  your  site,  you  should  be  able  to  establish  which  of  the  organization  s 

hosts  is  involved. 


Examine  the  network  traffic  logs  for  traffic  to  or  from  external  networks  other 
than  through  authorized,  secured  connections  and  gateways.  For  example  if  a 
user  has  added  a  modem  to  his  desktop  workstation  and  is  usmg  it  to  dial  up 
to  an  external  Internet  service  provider,  the  traffic  generated  will  bypass  his 
orgsuization’s  firewalled  Internet  connection. 


Resolve  all  instances  of  hardware  anomalies. 

Investigate  each  instance  of  new,  missing,  or  mislocated  hardware  to  deter¬ 
mine  if  the  changes  were  authorized. 

Report  any  confirmed  unauthorized  hardware  additions,  removals,  or  changes 
to  the  organization’s  security  contact  for  further  handling. 

Update  hardware  inventories  to  refiect  identified  changes  that  you  found  to  be 
authorized. 


Your  organization’s  networked  systems  security  policy  should 

•  Require  the  maintenance  of  documented  hardware  inventories. 

•  Require  the  maintenance  of  a  documented  network  topology. 

•  Specify  the  authority  and  responsibility  of  designated  security  personnel  to 
perform  physical  audits  of  installed  hardware  and  software. 

•  Specify  what  kinds  of  hardware  and  software  users  are  permitted  to  install 
themselves  on  their  desktop  machines. 
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other  information 


In  addition  to  the  periodic  inspections  of  hardware  recommended  above,  you 
may  need  to  conduct  inspections  in  response  to  suspected  intrusions  Watch 
for  evidence  of  activities  that  indicate  unusual  access  to  your  network. 


Where  to  find  updates 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected 
technologies,  is  available  on  the  Web  at  URL: 

http; //WWW . cert . org/security-improveinent/practices/p006 . html 


25 


CMU/SEI-SIM-001 


7 


Why  this  is  important 


How  to  do  it 


Look  for  signs  of  unauthorized  access  to  physical 
resources. 


Although  we  tend  to  think  of  the  information  in  networked  computer  systems 
as  being  in  electronic  form,  we  should  remember  that  that  information  is  held 
on  physical  media— tapes,  disks,  paper— and  these  media  are  physical  objects 
subject  to  physical  compromise  by  theft,  destruction,  corruption,  or  unautho¬ 
rized  duplication.  To  ensure  the  security  of  your  network,  you  should  also 
ensure  the  physical  security  of  its  components  by  periodically  inspecting  them 
for  possible  compromise. 

In  many  organizations,  there  will  be  personnel  responsible  for  the  physical 
security  of  the  premises.  However,  as  a  system  or  network  administrator,  you 
are  often  in  a  unique  position  to  notice  signs  of  physical  access  to  computing 
and  network  resources. 


If  a  document  or  electronic  storage  medium  is  stolen,  the  confidentiality  and 
availability  of  the  information  it  contained  is  lost.  Even  if  the  item  is  recov¬ 
ered,  you  won’t  know  the  extent  to  which  its  contents  have  been  copied  and 
disseminated.  Also,  you  won’t  know  whether  the  information  it  contains  has 
been  damagingly  corrupted  or  altered.  Furthermore,  if  the  compromised  infor¬ 
mation  is  security  critical,  for  example,  user  passwords,  internal  network 
addresses,  or  system  configuration  data,  your  entire  network  is  imder  threat 
from  further,  deeper,  and  more  damaging  intrusions. 

Therefore,  it  is  just  as  important  for  you  to  keep  track  of  physical  resources 
and  to  promptly  detect  attempts  at  physical  intrusion  and  access  as  it  is  for 
you  to  track  and  protect  yorir  electronic  resources. 


>•  Daily,  check  all  physical  means  of  entrance  or  exit  for  signs  of  tampering,  tres¬ 
pass,  or  attempted  trespass. 

Keep  in  mind  that  intruders  have  many  strategies  for  obtaining  confidential 
or  security-critical  documents.  For  example,  they  may  steal  discarded  copies  of 
reports,  console  logs,  system  printouts,  or  other  sensitive  data.  They  search 
through  trash  containers  or  dumpsters  to  find  carelessly  discarded  physical 
copies.  They  may  also  attempt  to  steal  backup  or  archive  tapes,  whose  disap¬ 
pearance  may  not  be  noticed  for  some  time. 


^  Duilyj  check  physical  resouvces  for  sigfis  of  tamperiTig. 

For  example,  inspect  locks  or  seals  on  hardware  cabinets,  review  console  logs, 
and  monitor  paper  usage. 

>■  Weekly  or  monthly,  perform  a  physical  audit  of  all  movable  media. 

Ensure  that  write-disabled  media  continue  to  be  so. 

Note  that,  as  a  complementary  practice,  you  should  also  audit  the  contents  of 
the  media  for  electronic  integrity. 

>  Report  all  signs  of  unauthorized  physical  access  to  your  organization  s  internal 
security  point  of  contact. 


Policy  considerations  Your  organization’s  networked  systems  security  policy  should 

•  Require  the  tagging  and  inventory  of  all  physical  computing  resources. 

•  Specify  how  to  respond  when  a  physical  intrusion  has  been  detected. 


! 

Where  to  find  updates 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected 
technologies,  is  available  on  the  Web  at  URL 

http : //WWW . cert . org/ security- improvement/practices/pO 07 .html 
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Review  reports  by  users  and  external  contacts  about 
suspicious  system  and  network  events  and  behavior. 


Why  this  is  important 


How  to  do  it 


In  security-conscious  organizations,  users  of  networked  systems  will  report 
suspicious  events  and  behaviors.  You,  as  a  system  or  network  administrator, 
should  use  those  reports  along  with  information  you  gather  yourself  to  help 
identify  possible  intrusions.  In  addition,  you  should  use  external  sources  of 
information,  such  as  the  reports  from  incident  response  teams,  where  appro¬ 
priate  to  help  you  plan  your  system  monitoring  and  incident  analysis  efforts. 


Recruiting  users  and  external  contacts  to  assist  you  in  security  monitoring 
greatly  extends  your  abiUty  to  detect  intrusions.  Not  only  do  they  represent 
extra  eyes,  they  can  often  be  more  aware  of  the  “normal”  behavior  of  their  per¬ 
sonal  computing  environments  than  you  are.  Many  intrusions  are  not  discov¬ 
ered  imtil  someone  with  day-to-day  experience  using  a  particular  system 
notices  something  unusual. 

Intruders  often  compromise  multiple  systems  when  they  attack  a  target  site. 
At  each  compromised  system,  there  may  be  telltale  signs  of  intrusive  activities 
that  users  of  the  system  discover.  Although  a  single  user  report  may  not  be 
sufficient  evidence  of  an  intrusion,  analysis  of  several  reports  may  reveal  a 
pattern  of  attack  imderway.  By  consolidating  users’  reports  of  suspicious  sys¬ 
tem  behaviors,  you  may  also  be  able  to  determine  how  widespread  attacks 
against  your  networked  systems  are. 

As  intrusions  into  networked  systems  at  other  organizations  occur,  adminis¬ 
trators  at  those  organizations  may  contact  your  organization  if  they  have  rea¬ 
son  to  believe  that  the  intrusion  may  also  involve  or  affect  your  organization. 
Reports  you  receive  from  incident  response  teams,  such  as  the  CERT  Coordi¬ 
nation  Center,  should  always  be  investigated  thoroughly  to  determine  if  in 
fact  an  intrusion  has  occurred  at  your  site.  If  your  network  environment  sup¬ 
ports  connections  to  external  networks,  it  is  possible  that  your  systems  may  be 
involved  in  a  large-scale  attack  against  several  sites. 


>•  Perform  “triage”  upon  receipt  of  a  report. 

Immediately  gather  as  much  information  as  necessary  to  make  an  initial 
assessment  of  whether  there  is  a  probable  intrusion  and,  if  so,  how  severe  it 
seems  to  be.  You  may  need  to  make  direct  contact  with  the  user  to  get  a 
description  of  what  was  observed.  Also  acquire  any  records  or  data  from  log¬ 
ging,  monitoring,  or  other  facilities  that  illustrate  the  problem.  If  the  informa¬ 
tion  clearly  indicates  an  intnision  attempt,  investigate  it  immediately. 


>■  Evaluate,  correlate,  and  prioritize  reports. 

On  a  regular  basis  (daily,  if  possible),  review  all  user  and  external  reports. 
These  include  new  reports,  reports  currently  under  investigation,  and  any 
that  remain  unresolved  after  investigation.  Look  for  correlations  or  patterns 
among  the  reports.  Prioritize  and  schedule  investigations  of  all  reports  based 
on  your  assessment  of  their  severity.  If  a  reported  suspicion  is  unfounded, 
close  the  report  and  reassure  the  user  who  reported  the  problem. 

>  Investigate  each  report  or  set  of  related  reports. 

Based  on  the  nature  of  the  report,  you  may  need  to  contact  other  users  to  doc¬ 
ument  their  observations.  You  may  also  need  to  verify  the  integrity  of  directo¬ 
ries  and  files,  examine  your  system  and  network  logs,  examine  processes  on 
affected  systems,  and  install  additional  monitoring  mechanisms  to  identify 
the  cause  of  the  anomalous  behavior. 

If  an  intrusion  has  been  discovered,  initiate  your  intrusion  response  procedures 
immediately. 

>  Document  and  report  your  findings. 

Regardless  of  your  investigation’s  outcome,  record  and  report  your  findings  to 
the  users  who  submitted  the  reports,  system  and  network  administrators,  and 
security  personnel  in  your  organization,  and  other  appropriate  individuals  as 
specified  in  your  organization’s  policies. 


Policy  considerations  Your  organization’s  networked  systems  security  policy  should 

•  Require  users  to  report  any  unexpected  or  suspicious  system  behavior 
immediately  to  their  designated  security  officials  and  system  administra¬ 
tors. 

•  Require  users  to  report  any  physical  intrusions  to  networked  systems  or 
offline  data  storage  facilities  immediately  to  their  designated  security  offi¬ 
cials  and  system  administrators. 

•  Require  system  administrators  to  investigate  each  reported  suspicious 
activity  to  determine  whether  it  represents  an  intrusion. 

•  Require  system  administrators  to  notify  users  in  advance  of  any  changes 
that  will  be  made  to  the  systems  they  use,  including  software  configura¬ 
tions,  data  storage  and  access,  and  revised  procedures  for  using  systems  as 
a  result  of  the  changes. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected 

technologies,  is  available  on  the  Web  at  URL 

http : //www . cert . org/ seourity-iaprovement/practices/pOOS . html 
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